Striving for correctness

ion layers, conceptually illustrated in Table 1. The security engineer must understand that the device designer, circuit designer, and operating system architect have different viewpoints. Each specialist assumes that the interface provided to him or her by the underlying layer is primitive and trustworthy. This trust is a consequence of specialization. Engineers working at one technological level of abstraction are usually not prepared to investigate and determine the trustworthiness of the resources with which they work. For example, software experts rarely know about hardware design. However, they tend to view hardware as a monolithic entity and to trust it. This trust may or may not be warranted. The hardware may be failure prone due to errors in design or fabrication, the assumptions upon which the hardware is being used may be false, or it may also have been built with malicious intent to sustain the same kinds of attacks as are commonly implemented in software, such as viruses and Trojan horses. See [2] for further discussion. Similarly, software experts who build trusted computing bases or communications protocol interpreters are users of supporting software, such as compilers and editors. They assume that this supporting software is trustworthy. While this is usually the case, Thompson [3] eloquently advises that one should be careful about extending trust. Recent work has described critical issues related to software trust and has proposed a set of criteria classes for measuring and comparing trust [4]. Addressing the trustworthiness of these layers is a matter of risk management. Absolute risk avoidance would address every possible level of risk. Risks might exist in the design of the chips, the TABLE 1. Abstraction layers Applications Security subsystem Operating system Compilers, loaders, etc. Circuit design and fabrication Semiconductor chip design side-effects of instruction set design (especially unimplemented instructions in complex instruction set architectures), or the security flaws in all supporting software. It has been common when confidentiality was the only security policy to assume that mass-produced bedrock was a sufficiently low risk that it could be ignored. Consideration of integrity and availability as security policies may justiftreconsideration. 1.3 The gods have clay feet-the emperor is naked This paper tends to proclaim that the gods have clay feet or that the emperor is naked. These are never popular sentiments. They are presented as constructively as possible, but we humbly acknowledge that we have no completely satisfactory answer. Our overall challenge to the community is the traditional engineer’s problem of finding cost-effective ways of applying the knowledge and skill base to the solution of social problems and requirements. This paper looks at the practical application of research results and finds a lack of evidence to support the very strong beliefs in the efficacy of various methods for increasing IT security. 1.4 Assurance, effectiveness and correctness Assurance is defined3 as “the confidence that may be held in the security provided by a target of evaluation.” Informally, assurance is a “warm fuzzy feeling” that the system can be relied upon to reduce residual risk to the predetermined level. Without delving into psychology, we observe that effectiveness and correctness both contribute to assurance. Efictiveness is determined by analysis of the functional requirements; the environment in which the system will be used, the risks, threats, and vulnerabilities; and all the countermeasures, including physical, administrative, procedural, personnel, and technical. The system is considered effective if the result of this analysis is an acceptable residual risk. Correctness is determined by ‘Definitions of assurance, correctness, and effectiveness are taken from the Information Technology Security Evaluation Criteria (ITSEC) (51. Better definitions may be available by the time this paper is published.